Mobile devices such as smartphones, tablets and e-readers, are often used to view content on the Internet, purchase goods online, perform online banking transactions and check bank balances. Mobile device users regularly view data or perform transactions which require them to enter passwords before they are authorised to complete the transaction. However, mobile devices—just like conventional PCs—are susceptible to malware infection, and it can be difficult to enter confidential data securely, or important transactional data without the risk of tampering. Once a mobile device becomes compromised, the malicious software may record any confidential data entered by the user of the device and send it to a third party, or alter the data entered to cause the user to perform an unintended action, or alter data displayed to the user on the device in order to deceive the user (e.g. to cause the user to enter further confidential information). Malware attacks can result in a loss of funds, privacy and safety. Thus, there is a need to be able to enter data securely into a device (i.e. secretly or without the data being tampered with), such that any malware on the device cannot interfere with the process.
Many customers access their bank accounts online using their mobile devices. Financial institutions have set up a number of processes to decrease the risk that a customer's account is accessed without authorisation. For example, most institutions use secure websites (i.e. HTTPS communication protocol) for online banking, and most require at least one password to be entered to authorise access. Many banks use a OTP system to control access to an account and to authorise online banking transactions. Typically, a customer is required to enter a password and is used to log in to the website, and an OTP (one-time password) which is a password that is valid for only one login session or transaction, to authenticate a particular transaction. OTPs can be used in several different approaches.
An OTP may be sent by the bank to a customer's mobile phone via an SMS message. If the OTP is sent to the customer via SMS, the customer has to switch back and forth between the website and the SMS application on their mobile device in order to read the SMS, memorize the OTP and enter it on the website. Users may find this approach inconvenient or difficult to carry out.
The customer may generate OTPs when required by using a secure token. The secure token is typically a piece of hardware, which includes a clock or a counter. Consequently, time and event ordering is an important part of an OTP generation algorithm. Alternatively, the OTP may be generated by the customer using a chip authentication program (CAP) device, which is described in more detail below. Whichever method is used to generate the OTP, the user then enters the OTP into the bank's website in order to complete the online transaction.
A number of banks use the chip authentication program (CAP) for authenticating online banking transactions. CAP is a two-step authentication system, which requires both a “chip and PIN” bank card (or chip card) and a valid PIN in order to generate an OTP. A user who has logged-in to their online banking account and who wishes to perform a transaction (e.g. transferring money between accounts or making a payment) must enter the OTP generated using CAP into the online banking system in order for their transaction to succeed. CAP requires the use of a handheld device, or CAP reader, which typically comprises a card slot, a numeric keypad and a display capable of displaying a number of characters/digits. Users wishing to make an online banking transaction are required to insert their “chip and PIN” bank card into the card slot and enter their PIN into the CAP reader via the keypad. The user may also select the type of transaction they wish to make, as well as details of the transaction. The CAP reader outputs a numeric passcode (i.e. an OTP) generated using the PIN, bank card-specific data and the current time. The user is required to enter the OTP online to complete the banking transaction.
CAP requires users who wish to perform online transactions via their mobile devices to carry the CAP reader with them. FIG. 1 illustrates the relative sizes of a smartphone 22, a smartphone case 30, a chip and pin bank card (or EMV card) 32 and a CAP reader 34. As shown in FIG. 1, typical CAP readers 34 may be of a similar size to many smartphones 22, and thus, the user may find it cumbersome to carry an additional device with them. The CAP approach may also be unappealing to users because it requires them to use two different devices with two different user interfaces in order to complete a secure transaction. Furthermore, a CAP reader is only used for particular bank-related transactions and cannot be used to securely enter passwords or perform other actions which require entry of confidential user data.
Smartphones are typically only software-protected and consequently, smartphones and similar mobile devices are not yet widely used to store, or trusted to store, very sensitive information. For example, smartphones may not be trusted to store the confidential information that is stored in the chip of a debit or credit card. In contrast, the chip within a debit or credit card is generally considered to be sufficiently secure. One reason for the lack of security on smartphones is that, in spite of the fact that a chip or microprocessor of the smartphone contains a so-called secure element (that in theory could provide secure storage and adequate protection), this ‘secure element’ is entirely controlled by the operator of the telephone network. That is, this smartphone chip is not typically accessible to software apps supplied, for example, by banks to perform secure transactions (e.g. online banking transactions via a smartphone). Thus, the smartphone's ‘secure element’ is not used when a smartphone is used to perform a transaction, and as a result, smartphones are not able to store sensitive information securely particularly during a transaction.
Background information can be found in: EP1467275A2, U.S.2013/0120913, U.S.2013/0077235, U.S.2003/0073415, U.S.2002/0089410 and EP1971111A2.
The present applicant has recognised the need to enhance the user experience of secure mobile computing.